How can I test the load capacity of a website (Stress Test)?
Greetings, friends!
Imagine this scenario: you launch a major ad campaign, announce a massive sale, or your technical tutorial suddenly goes viral. Thousands of users flood your website simultaneously, and instead of the long-awaited conversions or views, the server crashes with a terrifying 502 Bad Gateway or 504 Gateway Timeout error. The infrastructure failed to withstand the onslaught, the business loses revenue and customer loyalty, and the admin team frantically tries to restart Docker containers in a panic.
To prevent this nightmare, there is performance and stress testing. This is a simulation of an extreme influx of visitors under artificial, controlled conditions. Its goal is to intentionally drive the server to its breaking point, uncover bottlenecks in the code or database configuration, and understand the actual load your project can sustain. Conducting such a test is vital for any server or website so that you don't lose clients during peak loads. I would compare this to benchmarking a personal computer: hardware should be tested under load once in a while to detect hidden issues early.
In this material, we will break down the methodology of conducting a proper stress test in 2026, look at the best modern traffic generation tools, and learn how to interpret the results.
Key Takeaways: Main Points About Stress Testing
Find the Breaking Point: A stress test is not just a stability check; it is a search for infrastructure limits. You must increase the load until the site starts throwing errors or slows down critically. Then you will know your server's exact limit and can upgrade server specifications or adjust your architecture in time.
Test from the Outside, Not Inside: Never run a load generator on the same server hosting the website. The test process will consume the application's resources, rendering the results false.
Protect the Local Channel: Home internet or office Wi-Fi will become a bottleneck during the test. Load must be generated from third-party cloud VPS/VDS nodes with a guaranteed gigabit network port.
Monitor Metrics: The test itself is useless without parallel monitoring (Netdata, Prometheus/Grafana, or Uptime Kuma). You need to see exactly what the server is hitting: CPU, RAM, disk IOPS, or web server limitations.
Installing a Monitoring Application
On our YouTube channel, we recorded a video covering the installation of various monitoring tools. In this article, we will look at deploying Netdata, a convenient tool for tracking real-time server telemetry:
You will find all the setup commands in the video description and the pinned comment. With them, you can easily install the monitoring agent on Ubuntu, start the service, configure the UFW firewall, and access the Netdata web interface on port 19999.
Load, Stress, Spike, or Soak: What's the Difference?
Many people confuse types of performance testing, running a standard linear test and calling it a stress test.
To understand the shapes of traffic patterns, look at the comparison table below:
| Testing Type | How Load is Applied | Primary Goal | What is Verified |
| Load Testing | Expected peak (e.g., 500 users over an hour). | Verification of performance under standard production conditions. | Stability of response time (Response Time). |
| Stress Testing | Load grows gradually until failure (0 to 5000+ users). | Finding the physical threshold and critical ceiling of the system. | The exact point where the server starts throwing 5xx errors. |
| Spike Testing | Immediate, explosive spike in traffic within seconds. | Simulating viral traffic hits or sudden user influxes. | Whether the server can rapidly scale up processes. |
| Soak Testing | Average load over a long duration (24–48 hours). | Uncovering hidden infrastructure defects. | Detection of memory leaks (Memory Leaks) in software. |
Traffic Generation Tools: What to Choose?
The choice of utility directly impacts how clean and valid your test results will be. Good old ab (ApacheBench) from the 2000s can no longer keep up: it runs on a single CPU thread and quickly hits its own performance ceiling, failing to fully load modern multi-core hardware.
In 2026, two solutions have become industry standards:
k6 (by Grafana): Written in Go, incredibly fast, perfectly utilizes all CPU cores, and consumes minimal RAM. Test scenarios are written in familiar JavaScript.
Locust: Written in Python. Slightly more resource-hungry, but features an excellent web interface, real-time graphs, and allows writing complex, flexible user behavior scenarios in pure Python.
Step-by-Step Stress Testing Algorithm
To ensure you don't bring down a production project in the middle of a workday and to gather objective data, adhere to a strict testing protocol:
Step 1. Prepare an Isolated Environment
Never conduct a live stress test on a production server while real clients are using it. Create an exact replica (snapshot) of your system on a separate server, migrate the database, and configure Docker containers and Nginx in an identical layout.
Step 2. Select and Configure the Load Generator
Rent one or more third-party VPS instances to act as "clients." Install k6, for instance. Write a basic script that doesn't just request the site's homepage but simulates actual user behavior: visit the homepage, navigate to the catalog, and send a POST request to a search form. Standard static asset parsing only loads the network card, whereas heavy database queries stress the processor.
Step 3. Run the Test with a Gradual Ramph-Up
Start the test with low numbers—for example, 10 virtual users (Virtual Users / VU). Every 2 minutes, ramp up this number: 50 -> 200 -> 500 -> 1000 -> 2000. Closely monitor the response time graph. The moment the Response Time curve spikes upward and the web server begins returning errors, halt the test. You have found the limit.
Step 4. Analyze Bottlenecks
Examine the target server's monitoring reports at the peak of the load:
CPU at 100%, RAM free: The bottleneck is in the application code (poor script optimization) or a low single-core CPU frequency.
RAM maxed out, CPU idling: Incorrectly configured PHP-FPM, Docker, or MySQL buffer limits (the system has entered SWAP).
Resources free, but site throws errors: You have hit operating system limitations (such as the open files limit
ulimitor max connections in Nginxworker_connections).
FAQ: Quick Summary
Can a provider mistake a stress test for a DDoS attack?
Yes, and in 95% of cases, that is exactly what will happen. Automatic data center defense systems will detect an avalanche of UDP or TCP requests from a single IP address and block it at the perimeter. Before starting large-scale testing, always notify your hosting provider's technical support about the planned window. Otherwise, you risk getting your IP addresses banned by the provider.
What is the difference between RPS and Concurrency?
Concurrency represents the number of users maintaining an active, simultaneous connection to your website. RPS (Requests Per Second) is the number of individual requests the server processes in a single second. A single user actively clicking through pages can generate 10–20 RPS due to loading assets and API calls.
Conclusion
Stress testing is the only way to objectively evaluate the resilience of your IT infrastructure before real-world extreme loads put it to the test. Regular audits allow you to optimize configuration files in time, discover heavy SQL queries, and accurately calculate server scaling budgets as your business grows.
When generating and sustaining peak loads, the integrity and stability of the physical hardware are critical. If the server's virtual cores are shared with dozens of other clients (overselling), the system will begin to lag long before reaching its theoretical limits due to hidden hypervisor constraints.
Article Author — Anatolie Cohaniuc